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Abstract 


Encrypted Key Transport (EKT) is an extension to DTLS (Datagram Transport Layer Security) and 
the Secure Real-time Transport Protocol (SRTP) that provides for the secure transport of SRTP 
master keys, rollover counters, and other information within SRTP. This facility enables SRTP for 
decentralized conferences by distributing a common key to all of the conference endpoints. 


Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force (IETF). It represents the 
consensus of the IETF community. It has received public review and has been approved for 
publication by the Internet Engineering Steering Group (IESG). Further information on Internet 
Standards is available in Section 2 of RFC 7841. 


Information about the current status of this document, any errata, and how to provide feedback 
on it may be obtained at https://www.rfc-editor.org/info/rfc8870. 


Copyright Notice 


Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights 
reserved. 


This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF 
Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this 
document. Please review these documents carefully, as they describe your rights and restrictions 
with respect to this document. Code Components extracted from this document must include 
Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are 
provided without warranty as described in the Simplified BSD License. 
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1. Introduction 


The Real-time Transport Protocol (RTP) is designed to allow decentralized groups with minimal 
control to establish sessions, such as for multimedia conferences. Unfortunately, Secure RTP 
(SRTP) [RFC3711] cannot be used in many minimal-control scenarios, because it requires that 
synchronization source (SSRC) values and other data be coordinated among all of the 
participants in a session. For example, if a participant joins a session that is already in progress, 
that participant needs to be informed of the SRTP keys along with the SSRC, rollover counter 
(ROC), and other details of the other SRTP sources. 


The inability of SRTP to work in the absence of central control was well understood during the 
design of the protocol; the omission was considered less important than optimizations such as 
bandwidth conservation. Additionally, in many situations, SRTP is used in conjunction with a 
signaling system that can provide the central control needed by SRTP. However, there are several 
cases in which conventional signaling systems cannot easily provide all of the coordination 
required. 


This document defines Encrypted Key Transport (EKT) for SRTP and reduces the amount of 
external signaling control that is needed in an SRTP session with multiple receivers. EKT securely 
distributes the SRTP master key and other information for each SRTP source. With this method, 
SRTP entities are free to choose SSRC values as they see fit and to start up new SRTP sources with 
new SRTP master keys within a session without coordinating with other entities via external 
signaling or other external means. 


EKT extends DTLS and SRTP to enable a common key encryption key (called an "EKTKey") to be 
distributed to all endpoints, so that each endpoint can securely send its SRTP master key and 
current SRTP ROC to the other participants in the session. This data furnishes the information 
needed by the receiver to instantiate an SRTP receiver context. 


EKT can be used in conferences where the central Media Distributor or conference bridge cannot 
decrypt the media, such as the type defined in [RFC8871]. It can also be used for large-scale 
conferences where the conference bridge or Media Distributor can decrypt all the media but 
wishes to encrypt the media it is sending just once and then send the same encrypted media to a 
large number of participants. This reduces encryption CPU time in general and is necessary 
when sending multicast media. 
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EKT does not control the manner in which the SSRC is generated. It is only concerned with 
distributing the security parameters that an endpoint needs to associate with a given SSRC in 
order to decrypt SRTP packets from that sender. 


EKT is not intended to replace external key establishment mechanisms. Instead, it is used in 
conjunction with those methods, and it relieves those methods of the burden of delivering the 
context for each SRTP source to every SRTP participant. This document defines how EKT works 
with the DTLS-SRTP approach to key establishment, by using keys derived from the DTLS-SRTP 
handshake to encipher the EKTKey in addition to the SRTP media. 


2. Overview 


This specification defines a way for the server in a DTLS-SRTP negotiation (see Section 5) to 
provide an EKTKey to the client during the DTLS handshake. The EKTKey thus obtained can be 
used to encrypt the SRTP master key that is used to encrypt the media sent by the endpoint. This 
specification also defines a way to send the encrypted SRTP master key (with the EKTKey) along 
with the SRTP packet (see Section 4). Endpoints that receive this packet and know the EKTKey 
can use the EKTKey to decrypt the SRTP master key, which can then be used to decrypt the SRTP 
packet. 


One way to use this specification is described in the architecture defined by [RFC8871]. Each 
participant in the conference forms a DTLS-SRTP connection to a common Key Distributor that 
distributes the same EKTKey to all the endpoints. Then, each endpoint picks its own SRTP master 
key for the media it sends. When sending media, the endpoint may also include the SRTP master 
key encrypted with the EKTKey in the SRTP packet. This allows all the endpoints to decrypt the 
media. 


3. Conventions Used in This Document 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 
NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to 
be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in 
all capitals, as shown here. 


4. Encrypted Key Transport 


EKT defines a new method of providing SRTP master keys to an endpoint. In order to convey the 
ciphertext corresponding to the SRTP master key, and other additional information, an additional 
field, called the "EKTField", is added to the SRTP packets. The EKTField appears at the end of the 
SRTP packet. It appears after the optional authentication tag, if one is present; otherwise, the 
EKTField appears after the ciphertext portion of the packet. 


EKT MUST NOT be used in conjunction with SRTP's MKI (Master Key Identifier) or with SRTP's 
<From, To> [RFC3711], as those SRTP features duplicate some of the functions of EKT. Senders 
MUST NOT include the MKI when using EKT. Receivers SHOULD simply ignore any MKI field 
received if EKT is in use. 
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This document defines the use of EKT with SRTP. Its use with the Secure Real-time Transport 
Control Protocol (SRTCP) would be similar, but that topic is left for a future specification. SRTP is 
preferred for transmitting keying material because (1) it shares fate with the transmitted media, 
(2) SRTP rekeying can occur without concern for RTCP transmission limits, and (3) it avoids the 
need for SRTCP compound packets with RTP translators and mixers. 


4.1. EKTField Formats 


The EKTField uses the formats defined in Figures 1 and 2 for the FullEKTField and 
ShortEKTField. The EKTField appended to an SRTP packet can be referred to as an "EKT Tag". 


2) 1 2 3 
om2 3 4S Om 879r nET 7r 02AT NRR 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


EKT Ciphertext 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Security Parameter Index | Epoch 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Length 00 808000801 B 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 1: FullEKTField Format 


+ — + — tee eee 


oai 34567 
+-+-+-+-+-+-+-+-+ 
18800080808 8 
+-+-+-+-+-+-+-+-+ 


Figure 2: ShortEKTField Format 


Figure 3 shows the syntax of the EKTField, expressed in ABNF [RFC5234]. The EKTField is added 
to the end of an SRTP packet. The EKTPlaintext is the concatenation of SRTPMasterKeyLength, 
SRTPMasterKey, SSRC, and ROC, in that order. The EKTCiphertext is computed by encrypting the 
EKTPlaintext using the EKTKey. Future extensions to the EKTField MUST conform to the syntax of 
the ExtensionEKTField. 
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BYTE = %x00-FF 


EKTMsglypeFull = %x@2 

EKTMsgTypeShort = %x@0@ 

EKTMsgTypeExtension = %x@3-FF ; Message Type %x@1 is not available 
; for assignment due to its usage by 
; legacy implementations. 


EKTMsgLength = 2BYTE 

SRTPMasterKeyLength = BYTE 

SRTPMasterKey = 1*242BYTE 

SSRC = 4BYTE ; SSRC from RTP 

ROC = 4BYTE ; ROC from SRTP for the given SSRC 

EKTPlaintext = SRTPMasterKeyLength SRTPMasterKey SSRC ROC 
EKTCiphertext = 1*251BYTE ; EKTEncrypt(EKTKey, EKTPlaintext) 


Epoch = 2BYTE 
SPI = 2BYTE 


FullEKTField = EKTCiphertext SPI Epoch EKTMsgLength EKTMsgTypeFull 
ShortEKTField = EKTMsgTypeShort 


ExtensionData = 1*1024BYTE 
ExtensionEKTField = ExtensionData EKTMsgLength EKTMsgTypeExtension 


EKTField = FullEKTField / ShortEKTField / ExtensionEKTField 


Figure 3: EKTField Syntax 


These fields and data elements are defined as follows: 


EKTPlaintext: 
This is the data that is input to the EKT encryption operation. This data never appears on the 
wire; it is used only in computations internal to EKT. This is the concatenation of the SRTP 
master key and its length, the SSRC, and the ROC. 


EKTCiphertext: 
This is the data that is output from the EKT encryption operation (see Section 4.4). This field is 
included in SRTP packets when EKT is in use. The length of the EKTCiphertext can be larger 
than the length of the EKTPlaintext that was encrypted. 


SRTPMasterKey: 
On the sender side, this is the SRTP master key associated with the indicated SSRC. 


SRTPMasterKeyLength: 
This is the length of the SRTPMasterKey in bytes. This depends on the cipher suite negotiated 
for SRTP using Session Description Protocol (SDP) Offer/Answer [RFC3264]. 
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SSRC: 
On the sender side, this is the SSRC for this SRTP source. The length of this field is 32 bits. The 
SSRC value in the EKT Tag MUST be the same as the one in the header of the SRTP packet to 
which the tag is appended. 


Rollover Counter (ROC): 
On the sender side, this is set to the current value of the SRTP ROC in the SRTP context 
associated with the SSRC in the SRTP packet. The length of this field is 32 bits. 


Security Parameter Index (SPI): 
This field indicates the appropriate EKTKey and other parameters for the receiver to use 
when processing the packet, within a given conference. The length of this field is 16 bits, 
representing a two-byte integer in network byte order. The parameters identified by this field 
are as follows: 


e The EKT Cipher used to process the packet. 
e The EKTKey used to process the packet. 


e The SRTP master salt associated with any master key encrypted with this EKT Key. The 
master salt is communicated separately, via signaling, typically along with the EKTKey. 
(Recall that the SRTP master salt is used in the formation of Initialization Vectors (IVs) / 
nonces.) 


Epoch: 
This field indicates how many SRTP keys have been sent for this SSRC under the current 
EKTKey, prior to the current key, as a two-byte integer in network byte order. It starts at zero 
at the beginning of a session and resets to zero whenever the EKTKey is changed (i.e., when a 
new SPI appears). The epoch for an SSRC increments by one every time the sender transmits a 
new key. The recipient of a FullEKTField MUST reject any future FullEKTField for this SPI and 
SSRC that has an epoch value equal to or lower than an epoch already seen. 


Together, these data elements are called an "EKT parameter set". To avoid ambiguity, each 
distinct EKT parameter set that is used MUST be associated with a distinct SPI value. 


EKTMsgLength: 
All EKT Message Types other than the ShortEKTField include a length in octets (in network 
byte order) of either the FullEKTField or the ExtensionEKTField, including this length field 
and the EKT Message Type (as defined in the next paragraph). 


Message Type: 
The last byte is used to indicate the type of the EKTField. This MUST be 2 for the FullEKTField 
format and 0 for the ShortEKTField format. If a received EKT Tag has an unknown Message 
Type, then the receiver MUST discard the whole EKT Tag. 
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4.2. SPIs and EKT Parameter Sets 
The SPI identifies the parameters for how the EKT Tag should be processed: 


e The EKTKey and EKT Cipher used to process the packet. 


e The SRTP master salt associated with any master key encrypted with this EKT Key. The 
master salt is communicated separately, via signaling, typically along with the EKTKey. 


Together, these data elements are called an "EKT parameter set". To avoid ambiguity, each 
distinct EKT parameter set that is used MUST be associated with a distinct SPI value. The 
association of a given parameter set with a given SPI value is configured by some other protocol, 
e.g., the DTLS-SRTP extension defined in Section 5. 


4.3. Packet Processing and State Machine 


At any given time, the SSRC for each SRTP source has associated with it a single EKT parameter 
set. This parameter set is used to process all outbound packets and is called the "outbound 
parameter set" for that SSRC. There may be other EKT parameter sets that are used by other SRTP 
sources in the same session, including other SRTP sources on the same endpoint (e.g., one 
endpoint with voice and video might have two EKT parameter sets, or there might be multiple 
video sources on an endpoint, each with their own EKT parameter set). All of the received EKT 
parameter sets SHOULD be stored by all of the participants in an SRTP session, for use in 
processing inbound SRTP traffic. If a participant deletes an EKT parameter set (e.g., because of 
space limitations), then it will be unable to process Full EKT Tags containing updated media keys 
and thus will be unable to receive media from a participant that has changed its media key. 


Either the FullEKTField or ShortEKTField is appended at the tail end of all SRTP packets. The 
decision regarding which parameter to send and when is specified in Section 4.6. 


4.3.1. Outbound Processing 


See Section 4.6, which describes when to send an SRTP packet with a FullEKTField. Ifa 
FullEKTField is not being sent, then a ShortEKTField is sent so the receiver can correctly 
determine how to process the packet. 


When an SRTP packet is sent with a FullEKTField, the EKTField for that packet is created per 
either the steps below or an equivalent set of steps. 


1. The Security Parameter Index (SPI) field is set to the value of the SPI that is associated with 
the outbound parameter set. 

2. The EKTPlaintext field is computed from the SRTP master key, SSRC, and ROC fields, as 
shown in Section 4.1. The ROC, SRTP master key, and SSRC used in EKT processing MUST be 
the same as the one used in SRTP processing. 

3. The EKTCiphertext field is set to the ciphertext created by encrypting the EKTPlaintext with 
the EKTCipher using the EKTKey as the encryption key. The encryption process is detailed in 
Section 4.4. 


Jennings, et al. Standards Track Page 8 


RFC 8870 EKT SRTP January 2021 


4. Then, the FullEKTField is formed using the EKTCiphertext and the SPI associated with the 
EKTKey used above. Also appended are the length and Message Type using the FullEKTField 
format. 


Note: The value of the EKTCiphertext field is identical in successive packets 
protected by the same EKTKey and SRTP master key. This value MAY be cached by 
an SRTP sender to minimize computational effort. 


The computed value of the FullEKTField is appended to the end of the SRTP packet, after the 
encrypted payload. 


When a packet is sent with the ShortEKTField, the ShortEKTField is simply appended to the 
packet. 


Outbound packets SHOULD continue to use the old SRTP master key for 250 ms after sending any 
new key in a FullEKTField value. This gives all the receivers in the system time to get the new key 
before they start receiving media encrypted with the new key. (The specific value of 250 ms is 
chosen to represent a reasonable upper bound on the amount of latency and jitter that is 
tolerable in a real-time context.) 


4.3.2. Inbound Processing 


When receiving a packet on an RTP stream, the following steps are applied for each received 
SRTP packet. 


1. The final byte is checked to determine which EKT format is in use. When an SRTP packet 
contains a ShortEKTField, the ShortEKTField is removed from the packet and then normal 
SRTP processing occurs. If the packet contains a FullEKTField, then processing continues as 
described below. The reason for using the last byte of the packet to indicate the type is that 
the length of the SRTP part is not known until the decryption has occurred. At this point in 
the processing, there is no easy way to know where the EKTField would start. However, the 
whole SRTP packet has been received, so instead of starting at the front of the packet, the 
parsing works backwards at the end of the packet, and thus the type is placed at the very end 
of the packet. 


2. The Security Parameter Index (SPD field is used to find the right EKT parameter set to be 
used for processing the packet. If there is no matching SPI, then the verification function 
MUST return an indication of authentication failure, and the steps described below are not 
performed. The EKT parameter set contains the EKTKey, the EKTCipher, and the SRTP master 
salt. 


. The EKTCiphertext is authenticated and decrypted, as described in Section 4.4, using the 
EKTKey and EKTCipher found in the previous step. If the EKT decryption operation returns 
an authentication failure, then EKT processing MUST be aborted. The receiver SHOULD 
discard the whole SRTP packet. 

4. The resulting EKTPlaintext is parsed as described in Section 4.1, to recover the SRTP master 

key, SSRC, and ROC fields. The SRTP master salt that is associated with the EKTKey is also 

retrieved. If the value of the srtp_master_salt (see Section 5.2.2) sent as part of the EKTKey is 


OO 
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longer than needed by SRTP, then it is truncated by taking the first N bytes from the 
srtp_master_salt field. 

5. If the SSRC in the EKTPlaintext does not match the SSRC of the SRTP packet received, then 
this FulEKTField MUST be discarded and the subsequent steps in this list skipped. After 
stripping the FullEKTField, the remainder of the SRTP packet MAY be processed as normal. 


(op) 


. The SRTP master key, ROC, and SRTP master salt from the previous steps are saved in a map 
indexed by the SSRC found in the EKTPlaintext and can be used for any future crypto 
operations on the inbound packets with that SSRC. 


o Unless the transform specifies other acceptable key lengths, the length of the SRTP master 
key MUST be the same as the master key length for the SRTP transform in use. If this is not 
the case, then the receiver MUST abort EKT processing and SHOULD discard the whole 
SRTP packet. 


o If the length of the SRTP master key is less than the master key length for the SRTP 
transform in use and the transform specifies that this length is acceptable, then the SRTP 
master key value is used to replace the first bytes in the existing master key. The other 
bytes remain the same as in the old key. For example, the double GCM transform 
[RFC8723] allows replacement of the first ("end-to-end") half of the master key. 


7. At this point, EKT processing has successfully completed, and the normal SRTP processing 
takes place. 


The value of the EKTCiphertext field is identical in successive packets protected by the same EKT 
parameter set, SRTP master key, and ROC. SRTP senders and receivers MAY cache an 
EKTCiphertext value to optimize processing in cases where the master key hasn't changed. 
Instead of encrypting and decrypting, senders can simply copy the precomputed value and 
receivers can compare a received EKTCiphertext to the known value. 


Section 4.3.1 recommends that SRTP senders continue using an old key for some time after 
sending a new key in an EKT Tag. Receivers that wish to avoid packet loss due to decryption 
failures MAY perform trial decryption with both the old key and the new key, keeping the result 
of whichever decryption succeeds. Note that this approach is only compatible with SRTP 
transforms that include integrity protection. 


When receiving a new EKTKey, implementations need to use the ekt_ttl field (see Section 5.2.2) to 
create a time after which this key cannot be used, and they also need to create a counter that 
keeps track of how many times the key has been used to encrypt data, to ensure that it does not 
exceed the T value for that cipher (see Section 4.4). If either of these limits is exceeded, the key 
can no longer be used for encryption. At this point, implementations need to either use call 
signaling to renegotiate a new session or terminate the existing session. Terminating the session 
is a reasonable implementation choice because these limits should not be exceeded, except 
under an attack or error condition. 
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4.4. Ciphers 


EKT uses an authenticated cipher to encrypt and authenticate the EKTPlaintext. This 
specification defines the interface to the cipher, in order to abstract the interface away from the 
details of that function. This specification also defines the default cipher that is used in EKT. The 
default cipher described in Section 4.4.1 MUST be implemented, but another cipher that conforms 
to this interface MAY be used. The cipher used for a given EKTCiphertext value is negotiated 
using the supported_ekt_ciphers extension (see Section 5.2) and indicated with the SPI value in 
the FullEKTField. 


An EKTCipher consists of an encryption function and a decryption function. The encryption 
function E(K, P) takes the following inputs: 


e a secret key K with a length of L bytes, and 
e a plaintext value P with a length of M bytes. 


The encryption function returns a ciphertext value C whose length is N bytes, where N may be 
larger than M. The decryption function D(K, C) takes the following inputs: 


e a secret key K with a length of L bytes, and 
e a ciphertext value C with a length of N bytes. 


The decryption function returns a plaintext value P that is M bytes long, or it returns an 
indication that the decryption operation failed because the ciphertext was invalid (i.e., it was not 
generated by the encryption of plaintext with the key K). 


These functions have the property that D(K, E(K, P)) = P for all values of K and P. Each cipher also 
has a limit T on the number of times that it can be used with any fixed key value. The EKTKey 
MUST NOT be used for encryption more than T times. Note that if the same FullEKTField is 
retransmitted three times, that only counts as one encryption. 


Security requirements for EKT Ciphers are discussed in Section 6. 


4.4.1. AES Key Wrap 


The default EKT Cipher is the Advanced Encryption Standard (AES) Key Wrap with Padding 
algorithm [RFC5649]. It requires a plaintext length M that is at least one octet, and it returns a 
ciphertext with a length of N = M + (M mod 8) + 8 octets. It can be used with key sizes of L = 16 
octets or L = 32 octets, and its use with those key sizes is indicated as AESKW128 or AESKW256, 
respectively. The key size determines the length of the AES key used by the Key Wrap algorithm. 


With this cipher, T=24°. 


Cipher L T 


AESKW128 16 248 
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Cipher L T 
AESKW256 32 248 
Table 1: EKT Ciphers 


As AES-128 is the mandatory-to-implement transform in SRTP, AESKW128 MUST be implemented 
for EKT. AESKW256 MAY be implemented. 


4.4.2. Defining New EKT Ciphers 


Other specifications may extend this document by defining other EKTCiphers, as described in 
Section 7. This section defines how those ciphers interact with this specification. 


An EKTCipher determines how the EKTCiphertext field is written and how it is processed when it 
is read. This field is opaque to the other aspects of EKT processing. EKT Ciphers are free to use 
this field in any way, but they SHOULD NOT use other EKT or SRTP fields as an input. The values 
of the parameters L and T MUST be defined by each EKTCipher. The cipher MUST provide 
integrity protection. 


4.5. Synchronizing Operation 


If a source has its EKTKey changed by key management, it MUST also change its SRTP master key, 
which will cause it to send out a new FullEKTField and eventually begin encrypting with it, as 
described in Section 4.3.1. This ensures that if key management thought the EKTKey needs 
changing (due to a participant leaving or joining) and communicated that to a source, the source 
will also change its SRTP master key, so that traffic can be decrypted only by those who know the 
current EKTKey. 


4.6. Timing and Reliability Considerations 


A system using EKT learns the SRTP master keys distributed with the FullEKTField sent with 
SRTP, rather than with call signaling. A receiver can immediately decrypt an SRTP packet, 
provided the SRTP packet contains a FullEKTField. 


This section describes how to reliably and expediently deliver new SRTP master keys to 
receivers. 


There are three cases to consider. In the first case, a new sender joins a session and needs to 
communicate its SRTP master key to all the receivers. In the second case, a sender changes its 
SRTP master key, which needs to be communicated to all the receivers. In the third case, a new 
receiver joins a session already in progress and needs to know the sender's SRTP master key. 


The three cases are as follows: 


Jennings, et al. Standards Track Page 12 


RFC 8870 EKT SRTP January 2021 


New sender: 
A new sender SHOULD send a packet containing the FullEKTField as soon as possible, ideally 
in its initial SRTP packet. To accommodate packet loss, it is RECOMMENDED that the 
FullEKTField be transmitted in three consecutive packets. If the sender does not send a 
FullEKTField in its initial packets and receivers have not otherwise been provisioned with a 
decryption key, then decryption will fail and SRTP packets will be dropped until the receiver 
receives a FullEKTField from the sender. 


Rekey: 
By sending an EKT Tag over SRTP, the rekeying event shares fate with the SRTP packets 
protected with that new SRTP master key. To accommodate packet loss, it is RECOMMENDED 
that three consecutive packets containing the FullEKTField be transmitted. 


New receiver: 
When a new receiver joins a session, it does not need to communicate its sending SRTP 
master key (because it is a receiver). Also, when a new receiver joins a session, the sender is 
generally unaware of the receiver joining the session; thus, senders SHOULD periodically 
transmit the FullEKTField. That interval depends on how frequently new receivers join the 
session, the acceptable delay before those receivers can start processing SRTP packets, and the 
acceptable overhead of sending the FullEKTField. If sending audio and video, the 
RECOMMENDED frequency is the same as the rate of intra-coded video frames. If only sending 
audio, the RECOMMENDED frequency is every 100 ms. 


If none of the above three cases apply, a ShortEKTField SHOULD be sent. 


In general, sending FullEKTField tags less frequently will consume less bandwidth but will 
increase the time it takes for a join or rekey to take effect. Applications should schedule the 
sending of FullEKTField tags in a way that makes sense for their bandwidth and latency 
requirements. 


5. Use of EKT with DTLS-SRTP 


This document defines an extension to DTLS-SRTP called "SRTP EKTKey Transport", which 
enables secure transport of EKT keying material from the DTLS-SRTP peer in the server role to 
the client. This allows such a peer to process EKT keying material in SRTP and retrieve the 
embedded SRTP keying material. This combination of protocols is valuable because it combines 
the advantages of DTLS, which has strong authentication of the endpoint and flexibility, along 
with allowing secure multi-party RTP with loose coordination and efficient communication of 
per-source keys. 


In cases where the DTLS termination point is more trusted than the media relay, the protection 
that DTLS affords to EKT keying material can allow EKT Keys to be tunneled through an 
untrusted relay such as a centralized conference bridge. For more details, see [RFC8871]. 
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5.1. DTLS-SRTP Recap 


DTLS-SRTP [RFC5764] uses an extended DTLS exchange between two peers to exchange keying 
material, algorithms, and parameters for SRTP. The SRTP flow operates over the same transport 
as the DTLS-SRTP exchange (i.e., the same 5-tuple). DTLS-SRTP combines the performance and 
encryption flexibility benefits of SRTP with the flexibility and convenience of DTLS-integrated 
key and association management. DTLS-SRTP can be viewed in two equivalent ways: as a new 
key management method for SRTP and as a new RTP-specific data format for DTLS. 


5.2. SRTP EKT Key Transport Extensions to DTLS-SRTP 


This document defines a new TLS negotiated extension called "supported_ekt_ciphers" and a new 
TLS handshake message type called "ekt_key". The extension negotiates the cipher to be used in 
encrypting and decrypting EKTCiphertext values, and the handshake message carries the 
corresponding key. 


Figure 4 shows a message flow between a DTLS 1.3 client and server using EKT configured using 
the DTLS extensions described in this section. (The initial cookie exchange and other normal 
DTLS messages are omitted.) To be clear, EKT can be used with versions of DTLS prior to 1.3. The 
only difference is that in pre-1.3 TLS, stacks will not have built-in support for generating and 
processing ACK messages. 
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Figure 4: DTLS 1.3 Message Flow 
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In the context of a multi-party SRTP session in which each endpoint performs a DTLS handshake 
as a client with a central DTLS server, the extensions defined in this document allow the DTLS 


server to set a common EKTKey for all participants. Each endpoint can then use EKT Tags 


encrypted with that common key to inform other endpoints of the keys it uses to protect SRTP 
packets. This avoids the need for many individual DTLS handshakes among the endpoints, at the 
cost of preventing endpoints from directly authenticating one another. 
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5.2.1. Negotiating an EKTCipher 


To indicate its support for EKT, a DTLS-SRTP client includes in its ClientHello an extension of type 
supported_ekt_ciphers listing the ciphers used for EKT by the client, in preference order, with the 
most preferred version first. If the server agrees to use EKT, then it includes a 
supported_ekt_ciphers extension in its EncryptedExtensions (or ServerHello for DTLS 1.2) 
containing a cipher selected from among those advertised by the client. 


The extension_data field of this extension contains an "EKTCipher" value, encoded using the 
syntax defined in [RFC8446]: 


enum { 
reserved(@), 
aeskw_128(1), 
aeskw_256(2), 

} EKTCipherType; 


struct { 
select (Handshake.msg_type) { 
case client_hello: 
EKTCipherType supported_ciphers<1..255>; 


case server_hello: 
EKTCipherType selected_cipher ; 


case encrypted_extensions: 
EKTCipherType selected_cipher ; 


y; 
} EKTCipher; 


5.2.2. Establishing an EKT Key 


Once a client and server have concluded a handshake that negotiated an EKTCipher, the server 
MUST provide to the client a key to be used when encrypting and decrypting EKTCiphertext 
values. EKTKeys are sent in encrypted handshake records, using handshake type ekt_key(26). The 
body of the handshake message contains an EKTKey structure as follows: 


struct { 
opaque ekt_key_value<1..256>; 
opaque srtp_master_salt<1..256>; 
uint16 ekt_spi; 
uint24 ekt_ttl1; 

} EKTKey; 


The contents of the fields in this message are as follows: 


ekt_key_value 
The EKTKey that the recipient should use when generating EKTCiphertext values 
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srtp_master_salt 
The SRTP master salt to be used with any master key encrypted with this EKT Key 


ekt_spi 
The SPI value to be used to reference this EKTKey and SRTP master salt in EKT Tags (along 
with the EKT Cipher negotiated in the handshake) 


ekt_ttl 
The maximum amount of time, in seconds, that this EKTKey can be used. The ekt_key_value in 
this message MUST NOT be used for encrypting or decrypting information after the TTL 
expires. 


If the server did not provide a supported_ekt_ciphers extension in its EncryptedExtensions (or 
ServerHello for DTLS 1.2), then EKTKey messages MUST NOT be sent by the client or the server. 


When an EKTKey is received and processed successfully, the recipient MUST respond with an 
ACK message as described in Section 7 of [TLS-DTLS13]. The EKTKey message and ACK MUST be 
retransmitted following the rules of the negotiated version of DTLS. 


EKT MAY be used with versions of DTLS prior to 1.3. In such cases, to provide reliability, the ACK 
message is still used. Thus, DTLS implementations supporting EKT with pre-1.3 versions of DTLS 
will need to have explicit affordances for sending the ACK message in response to an EKTKey 
message and for verifying that an ACK message was received. The retransmission rules for both 
sides are otherwise defined by the negotiated version of DTLS. 


If an EKTKey message is received that cannot be processed, then the recipient MUST respond 
with an appropriate DTLS alert. 


5.3. Offer/Answer Considerations 


When using EKT with DTLS-SRTP, the negotiation to use EKT is done at the DTLS handshake level 
and does not change the SDP Offer/Answer messaging [RFC3264]. 


5.4. Sending the DTLS EKTKey Reliably 


The DTLS EKTKey message is sent using the retransmissions specified in Section 4.2.4 of DTLS 
[RFC6347]. Retransmission is finished with an ACK message, or an alert is received. 


6. Security Considerations 


EKT inherits the security properties of the key management protocol that is used to establish the 
EKTKey, e.g., the DTLS-SRTP extension defined in this document. 


With EKT, each SRTP sender and receiver MUST generate distinct SRTP master keys. This property 
avoids any security concerns over the reuse of keys, by empowering the SRTP layer to create keys 
on demand. Note that the inputs of EKT are the same as for SRTP with key-sharing: a single key is 
provided to protect an entire SRTP session. However, EKT remains secure even when SSRC 
values collide. 
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SRTP master keys MUST be randomly generated, and [RFC4086] offers some guidance about 
random number generation. SRTP master keys MUST NOT be reused for any other purpose, and 
SRTP master keys MUST NOT be derived from other SRTP master keys. 


The EKT Cipher includes its own authentication/integrity check. 


The presence of the SSRC in the EKTPlaintext ensures that an attacker cannot substitute an 
EKTCiphertext from one SRTP stream into another SRTP stream. This mitigates the impact of cut- 
and-paste attacks that arise due to the lack of a cryptographic binding between the EKT Tag and 
the rest of the SRTP packet. SRTP tags can only be cut-and-pasted within the stream of packets 
sent by a given RTP endpoint; an attacker cannot "cross the streams" and use an EKT Tag from 
one SSRC to reset the key for another SSRC. The Epoch field in the FullEKTField also prevents an 
attacker from rolling back to a previous key. 


An attacker could send packets containing a FullEKTField, in an attempt to consume additional 
CPU resources of the receiving system by causing the receiving system to decrypt the EKT 
ciphertext and detect an authentication failure. In some cases, caching the previous values of the 
ciphertext as described in Section 4.3.2 helps mitigate this issue. 


In a similar vein, EKT has no replay protection, so an attacker could implant improper keys in 
receivers by capturing EKTCiphertext values encrypted with a given EKTKey and replaying them 
in a different context, e.g., from a different sender. When the underlying SRTP transform 
provides integrity protection, this attack will just result in packet loss. If it does not, then it will 
result in random data being fed to RTP payload processing. An attacker that is in a position to 
mount these attacks, however, could achieve the same effects more easily without attacking EKT. 


The key encryption keys distributed with EKTKey messages are group shared symmetric keys, 
which means they do not provide protection within the group. Group members can impersonate 
each other; for example, any group member can generate an EKT Tag for any SSRC. The entity 
that distributes EKTKeys can decrypt any keys distributed using EKT and thus any media 
protected with those keys. 


Each EKT Cipher specifies a value T that is the maximum number of times a given key can be 
used. An endpoint MUST NOT encrypt more than T different FullEKTField values using the same 
EKTKey. In addition, the EKTKey MUST NOT be used beyond the lifetime provided by the TTL 
described in Section 5.2. 


The key length of the EKT Cipher MUST be at least as long as the SRTP cipher and at least as long 
as the DTLS-SRTP ciphers. 


Part of the EKTPlaintext is known or is easily guessable to an attacker. Thus, the EKT Cipher 
MUST resist known plaintext attacks. In practice, this requirement does not impose any 
restrictions on our choices, since the ciphers in use provide high security even when much 
plaintext is known. 


An EKT Cipher MUST resist attacks in which both ciphertexts and plaintexts can be adaptively 
chosen by an attacker querying both the encryption and decryption functions. 
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In some systems, when a member of a conference leaves the conference, that conference is 
rekeyed so that the member who left the conference no longer has the key. When changing to a 
new EKTKey, it is possible that the attacker could block the EKTKey message getting to a 
particular endpoint and that endpoint would keep sending media encrypted using the old key. To 
mitigate that risk, the lifetime of the EKTKey MUST be limited by using the ekt_ttl. 


7. IANA Considerations 


7.1. EKT Message Types 


IANA has created a new table for "EKT Message Types" in the "Real-Time Transport Protocol 
(RTP) Parameters" registry. The initial values in this registry are as follows: 


Message Type Value Specification 


Short 0 RFC 8870 
Unassigned 1 
Full 2 RFC 8870 
Unassigned 3-254 
Reserved 255 RFC 8870 


Table 2: EKT Message Types 


New entries in this table can be added via "Specification Required" as defined in [RFC8126]. To 
avoid conflicts with pre-standard versions of EKT that have been deployed, IANA SHOULD give 
preference to the allocation of even values over odd values until the even code points are 
consumed. Allocated values MUST be in the range of 0 to 254. 


All new EKT messages MUST be defined to include a length parameter, as specified in Section 4.1. 


7.2. EKT Ciphers 


IANA has created a new table for "EKT Ciphers" in the "Real-Time Transport Protocol (RTP) 
Parameters" registry. The initial values in this registry are as follows: 


Name Value Specification 
AESKW128 0 RFC 8870 
AESKW256 1 RFC 8870 


Unassigned 2-254 
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Name Value Specification 
Reserved 255 RFC 8870 
Table 3: EKT Cipher Types 


New entries in this table can be added via "Specification Required" as defined in [RFC8126]. The 
expert SHOULD ensure that the specification defines the values for L and T as required in Section 
4.4 of this document. Allocated values MUST be in the range of 0 to 254. 


7.3. TLS Extensions 


IANA has added supported_ekt_ciphers as a new extension name to the "TLS ExtensionType 
Values" table of the "Transport Layer Security (TLS) Extensions" registry: 


Value: 39 
Extension Name: supported_ekt_ciphers 
TLS 1.3: CH, EE 


Recommended: Y 


Reference: RFC 8870 


7.4. TLS Handshake Type 
IANA has added ekt_key as a new entry in the "TLS HandshakeType" table of the "Transport 


Layer Security (TLS) Parameters" registry: 
Value: 26 

Description: ekt_key 

DTLS-OK: Y 

Reference: RFC 8870 


Comment: 
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